Hey,
We have had the index number of every formal and link module in our DOORS (8.3) change overnight. This has caused every view that uses a trace to no longer work but the data and links are still fine. We are in the process of fixing the views but can not work out what has happened, which has us concerned it could happen again. Our IT dept has confirmed they haven't touched the server in weeks and the logs for the server support nothing strange happened.
I have heard that 8.3 had a bug where if you restore a backup it can cause the index numbers to change but I've restored the backup from the night this happened on another server and all the views work fine. So that theory isn't correct.
Has anyone ever had this happen to them before and work out what it was?
mjenke - Sun Nov 21 20:46:48 EST 2010 |
|
Re: Index numbers magicly change
SystemAdmin - Sun Nov 21 23:06:51 EST 2010
"...I have heard that 8.3 had a bug where if you restore a backup it can cause the index numbers to change..."
Have never heard of such a bug in 8.3, to me, such a bug would have been a show stopper and would have been widely known. 8.3 is back when Telelogic owned DOORS - a quick check of legacy support & forum data that I have for 8.3 doesn't reveal a reported\known bug like this.
The only way that I know of for the index numbers of modules to change is when you restore an archive of a DOORS project or module onto a DOORS database that was not the original database that the archive was created from.
Is this index change across all projects or just one project?
Even if it were a bug - it just seems too elegant that a bug can go through the entire database and re-index every module without there being other more potentially destructive problems. Sounds more like a built-in function than a bug if such a function existed with the doorsd.exe executable code.
Paul Miller
|
|
Re: Index numbers magicly change
mjenke - Mon Nov 22 01:10:52 EST 2010 SystemAdmin - Sun Nov 21 23:06:51 EST 2010
"...I have heard that 8.3 had a bug where if you restore a backup it can cause the index numbers to change..."
Have never heard of such a bug in 8.3, to me, such a bug would have been a show stopper and would have been widely known. 8.3 is back when Telelogic owned DOORS - a quick check of legacy support & forum data that I have for 8.3 doesn't reveal a reported\known bug like this.
The only way that I know of for the index numbers of modules to change is when you restore an archive of a DOORS project or module onto a DOORS database that was not the original database that the archive was created from.
Is this index change across all projects or just one project?
Even if it were a bug - it just seems too elegant that a bug can go through the entire database and re-index every module without there being other more potentially destructive problems. Sounds more like a built-in function than a bug if such a function existed with the doorsd.exe executable code.
Paul Miller
We only have 1 project in our database as this project has a separate server from all the others in the company.
Some more investigating today seems to be that the if we say had an index number of "47db0b073bcd0782-000004c1" only the first 16 hex number have changed, the last 8 are still the same. So I'm not sure how the numbers are broken up but if the last 8 are just the index for the module then they haven't accually changed and what ever the first 16 mean is what has changed.
Another theory being thrown around is that it was caused when a nightly backup was taken. But still have no idea on why..
|
|
Re: Index numbers magicly change
SystemAdmin - Tue Nov 23 08:28:07 EST 2010 mjenke - Mon Nov 22 01:10:52 EST 2010
I heard that from a guy here and so far it was the only thing to go by. But like I said when we restored our backup this wasn't the case and it restored fine.
We only have 1 project in our database as this project has a separate server from all the others in the company.
Some more investigating today seems to be that the if we say had an index number of "47db0b073bcd0782-000004c1" only the first 16 hex number have changed, the last 8 are still the same. So I'm not sure how the numbers are broken up but if the last 8 are just the index for the module then they haven't accually changed and what ever the first 16 mean is what has changed.
Another theory being thrown around is that it was caused when a nightly backup was taken. But still have no idea on why..
|
|
Re: Index numbers magicly change
llandale - Tue Nov 23 14:46:01 EST 2010
If you do a file system backup restore then the 'uniqueIDs' of everything is preserved. Most likely what happened is that someone did a 'restore' of a project 'archive' after purging the old project (perhaps it was corrupt). In that case, of course, the newly created modules will get their new 'uniqueIDs' and mess up your layouts. Also such a restore will remove all inter-project links, and I also believe for v9.0 erase all specific accesses the project may have. Hate it when that happens.
|
|
Re: Index numbers magicly change
mjenke - Tue Nov 23 19:31:11 EST 2010 llandale - Tue Nov 23 14:46:01 EST 2010
If you do a file system backup restore then the 'uniqueIDs' of everything is preserved. Most likely what happened is that someone did a 'restore' of a project 'archive' after purging the old project (perhaps it was corrupt). In that case, of course, the newly created modules will get their new 'uniqueIDs' and mess up your layouts. Also such a restore will remove all inter-project links, and I also believe for v9.0 erase all specific accesses the project may have. Hate it when that happens.
We are looking into the possiblity that a backup of the file system that was done without shutting down the server could have caused the problem.
|
|